Lightweight directory access protocol (LDAP) is an open industry standard defining a standard method for accessing and updating information in a directory. LDAP has gained wide acceptance as the directory access method of the internet and is therefore also becoming strategic within corporate intranets. It is being supported by a growing number of software vendors and is being incorporated into a growing number of applications.
A directory is basically a read-centric repository, wherein customers can store any kind of data they are permitted to see such as, for example, users, applications, files, printers, network resources, etc. With time and age, the needs of the customers have been increasing with regards to the feature-set a given directory server deployment provides. To work with the new feature set, customers need to migrate to the new version of the directory server. In a typical customer deployment, not all products would support migration. There can be some products which are tightly connected to the older version of the directory server. Migration of the directory server would need a migration of dependent products because of schema dependency.
Given a customer deployment, there can be ‘n’ number of products to have the solution fully functional. Assume that the deployment includes products A, B, C and D. The deployment also has a directory server component. Let's, as an example, refer to the directory server component as DSv1. The development team works on some new features and comes out with a new release of the directory server, for example, DSv2. Customers find the feature set in DSv2 quite interesting and they are keen to use the same and increase their product value. However, there are schema changes from DSv1 and DSv2 to support the new features introduced in DSv2. This forms a hindrance in migration. In the current product deployment, products A, C work with DSv2, but products B and D do not work with DSv2, rather they work only with DSv1. The migration, therefore, cannot go ahead because all the products cannot be migrated.
The entire deployment can be migrated to make all four products work with DSv2. One way to achieve this would be to upgrade B and D. However, this would mean that the customer has to invest further to upgrade B and D. Customers may not like this and may refrain from migration. However, to make B and D work with DSv2, one needs to ensure that the schemas of DSv1 and DSv2 are available in a single directory server instance, whereafter products can work with either of the schemas based upon their needs.
Existing approaches include versioning that is from a directory entry perspective, rather than at the schema level. Schema, as will be described below, is the backbone of entries in a directory server. Schema includes attributes and objectclasses. A directory entry is an instance of an objectclass. The attributes in the entries are the ones to which users can assign values.